Core Question

當模型輸出從文字變成可造成 side effect 的 Tool Call，哪些新的 principal、trust boundary 與 enforcement point 必須出現？

今天的問題

假設企業內有一個「客服工作助理」。使用者輸入：「請找出訂單編號 4821 的延遲原因，如果確認是倉庫問題，就建立一張補寄單，並通知客戶。」

傳統 chatbot 可能只回覆一段建議文字；Agent 則可能先查詢訂單，再呼叫倉儲 API 建立補寄單，最後呼叫通知工具寄出訊息。對使用者而言，兩者都像是在「回答」；對企業而言，後者已經跨過了從資訊處理到改變外部狀態的界線。

這不是在判斷模型是否聰明，也不是假設模型一定惡意。即使模型完全正常，模型輸出仍是未經授權的建議，不能直接等同於執行權力。

為什麼這不是傳統 IAM 問題

傳統 IAM 常把問題簡化成「某個 subject 能否存取某個 resource」。Agent 場景多了三個會改變安全邊界的因素：

1. 自然語言 intent 不等於 Action。「處理延遲訂單」可能被拆成查詢、判斷、建立補寄單、發信等多個 Action；每一步的資源、風險與副作用不同。
2. 模型可以規劃並連續呼叫 Tool。 權限不再只是一個登入 session 的靜態屬性，而是會隨 Task、參數與前一步結果改變的決策輸入。
3. 輸出開始碰到外部狀態。 查詢是 read-only；建立補寄單、寄信或退款則會產生 side effect。模型輸出一旦被直接接到有 credential 的工具，就變成一條未經治理的 authority path。

NIST 對 tool-use agent 的整理也把「能否寫入」、「是否可逆」、「自主程度」及可觀測性列為重要的工具使用與限制維度；這正是不能只以「有沒有登入」描述 Agent 風險的原因。NIST：Lessons Learned from the Consortium—Tool Use in Agent Systems

所以本文不會把 OAuth、JWT 或 RBAC 當成主角，而是先問三件事：Agent 是誰？它代表誰？它憑什麼執行這個具體 Action？

Threat / Failure Scenario：模型輸出直接拿到 credential

最容易出現的設計如下：Agent runtime 同時持有 WAREHOUSE_API_TOKEN 和 MAIL_API_TOKEN，模型回傳 JSON 後，程式依照 tool 欄位直接呼叫對應 API。

User prompt → Model → tool name + parameters → Tool API
                                      ↘ shared credential

這裡至少有五個問題：

• 模型可以選擇任何已註冊 Tool，卻沒有證明這次 Action 被允許。
• Tool 只看到同一組 service credential，無法分辨是哪個 Agent instance 或哪個 Task 發出請求。
• 使用者說「如果確認是倉庫問題」，被模型自行解讀成建立補寄單；intent 與實際 Action 沒有可驗證的 binding。
• 參數可能在最後一步被換掉，例如把 order_id=4821 改成另一筆訂單，或把通知收件者改成外部地址。
• 一旦 credential 洩漏，攻擊者不必再通過 Agent 的任務邏輯，便可直接造成 side effect。

這是典型的 confused deputy：模型或上游程式拿著比目前請求更大的權力，替另一個主體使用了資源。問題不在於「模型是否可信」，而在於真正的 enforcement point 太晚，甚至根本不存在。

核心概念：從回答邊界到 Action 邊界

Chatbot 的 data plane

純文字 chatbot 的主要資料流是：

User → UI → Model → Text response → User

模型產生的文字可能錯誤、誤導或包含不安全建議，但它本身沒有直接改變訂單、資料庫或郵件系統的能力。應用程式仍可在顯示、儲存或送出前加入檢查。

Agent 的 execution plane

Agent 需要另外處理執行平面：

User → Agent runtime → Model
             ↓ intent / plan / proposed Action
      Tool Gateway / PEP → Tool / API → Resource
                    ↑
              PDP decision

這裡至少要分開以下角色：

• User / User Identity： 發起任務的人；不代表使用者自動允許所有後續 Action。
• Agent / Agent Identity： 解析 intent、產生 plan、提出 Tool Call 的執行者；模型輸出本身不是 authority。
• Tool Gateway / PEP： 不可由 Agent 繞過的 enforcement point，驗證 identity、context 與決策結果。
• PDP： 根據 subject、actor、Action、Resource、Task 與 policy 產生 allow、deny 或 constraint。
• Tool / API： 執行具體操作，必要時仍應做 resource-level 檢查。
• Resource： 最終會被讀取或改變的訂單、資料庫、郵件或其他系統狀態。

NIST SP 800-207 將 Policy Enforcement Point 定義為控制主體與企業資源連線、監控並可終止連線的元件；套到 Agent，Tool Gateway 正是把「模型想做什麼」與「資源實際允許什麼」隔開的邊界。NIST SP 800-207：Zero Trust Architecture

Architecture Pattern

Naive / Unsafe Design

此設計把模型輸出的 tool 與 parameters 當成呼叫 API 的充分條件。它沒有獨立的 Action policy，也沒有可靠的位置確認「誰」提出請求、「代表誰」以及「為什麼這個參數可以造成這個副作用」。

即使在 API 端加上登入檢查，仍只回答了 authentication：「你持有 credential 嗎？」；它沒有回答 authorization：「這個 Agent 是否被允許為這個 Task 對這筆訂單建立補寄單？」

Recommended Design

推薦把模型輸出視為 proposed Action，交給不可繞過的 Gateway 重新驗證：

一次決策至少應帶有以下資料：

{
  "subject": "user:alice",
  "actor": "agent:customer-ops/instance-7",
  "task": "task:4821-delay-resolution",
  "action": "warehouse.create_reship",
  "resource": "order:4821",
  "constraints": {"reason": "warehouse_delay", "count": 1},
  "decision": "allow",
  "policy_version": "2026-08-12.1"
}

這不是要求每個系統立刻採用相同的 token 格式，而是要求架構上能分辨 User、Agent 與具體 Action。subject 表示任務代表誰，actor 表示實際執行的 Agent；兩者不能被一個共用 service account 壓平。

Trust Boundary 與 Identity Flow

本日先畫出四個邊界：

1. User ↔ Agent runtime： 使用者 intent 進入 Agent；prompt 不自動成為 permission。
2. Agent runtime ↔ Tool Gateway： Agent 提出 Action，Gateway 驗證 Agent Identity、Task context、audience 與 delegation context。
3. Gateway / PDP ↔ Tool： Gateway 只轉送通過決策且受 constraints 約束的請求；Tool 不能信任 Agent 自己放入的 header。
4. Tool ↔ Resource： 最終 API 仍可依 resource owner、資料敏感度或狀態做第二層檢查。

因此 Identity Flow 應是「User Identity + Agent Identity + Task / Action context」一起抵達決策點，而不是 User token 被原封不動轉送，或 Agent 自報 X-Agent-Id 就被接受。

Authorization Decision Point：逐 Action，而不是逐連線

PDP 的最小決策單位應是具體 Action，而不是「Agent 能不能連上 MCP server」或「Agent 是否被加入工具清單」。例如：

每個 decision 都應留下 correlation ID、subject、actor、Action digest、resource、policy version、decision、constraint 與 Tool outcome。這讓後續調查可以回答「誰代表誰做了什麼」，而不是只看到一筆模糊的 API log。

小型 PoC：同一個輸出，兩種安全邊界

以下程式只使用 Python 標準庫，模擬同一個模型輸出。在 read-only chatbot 路徑，輸出只是文字；在 Agent 路徑，輸出必須先通過本地 Gateway 的逐 Action policy。將程式存成暫存檔執行即可，不需要安裝套件。

import json

model_output = {
    "tool": "warehouse.create_reship",
    "parameters": {"order_id": "4821", "reason": "warehouse_delay", "count": 1},
}

def chatbot_path(proposed):
    return "建議執行：" + json.dumps(proposed, ensure_ascii=False)

def agent_gateway(proposed, task):
    p = proposed["parameters"]
    allowed = (
        proposed["tool"] == "warehouse.create_reship"
        and p["order_id"] == task["order_id"]
        and p["reason"] == "warehouse_delay"
        and p["count"] == 1
    )
    if not allowed:
        return {"decision": "deny", "reason": "Action 不符合 task constraints"}
    return {"decision": "allow", "resource": "order:" + p["order_id"]}

task = {"order_id": "4821"}
print("chatbot:", chatbot_path(model_output))
print("agent:", agent_gateway(model_output, task))

tampered = {**model_output, "parameters": {**model_output["parameters"], "order_id": "7730"}}
print("tampered agent:", agent_gateway(tampered, task))

預期結果：

chatbot: 建議執行：{"tool": "warehouse.create_reship", ...}
agent: {'decision': 'allow', 'resource': 'order:4821'}
tampered agent: {'decision': 'deny', 'reason': 'Action 不符合 task constraints'}

這個 PoC 沒有模擬真實模型、token 或 API server，因為本日要證明的不是某個產品的整合方式，而是 enforcement point 的位置：同一段輸出在沒有 side effect 的 data plane 與有 side effect 的 execution plane，必須走不同的安全路徑。

今天得到什麼

• Agent Security 的核心變化，是模型輸出跨越了可執行權力的邊界，而不是模型「更像人」或「更聰明」。
• 模型輸出是 intent 或 proposed Action，不是 authorization；Tool credential 不能直接交給模型決定如何使用。
• User Identity、Agent Identity、Task context 與具體 Action 必須在 Gateway / PDP 匯合，並由 PEP 強制執行。
• Tool discovery、authentication 與 authorization 是不同層次；能看到或連上 Tool，不代表能執行所有操作。
• 每次 allow、deny 與實際 side effect 都應留下可關聯的 evidence，讓事後能重建「誰、代表誰、憑什麼做了什麼」。

下一篇

今天先證明 Agent 需要一條獨立的執行與授權邊界；但 Tool 到底應該把 Agent 視為使用者、應用程式，還是 workload？下一篇會拆開 User Identity、Agent Identity、Agent definition 與 runtime instance，回答「一個 Agent 到底算哪一種 security principal？」

參考資料

• NIST：Lessons Learned from the Consortium—Tool Use in Agent Systems
• NIST SP 800-207：Zero Trust Architecture
• NIST：AI Agent Standards Initiative